Testing your code - what, why and how?

Tim Taylor
Friday 5th March 2020

LSHTM Software Chatter

Plan for this session

  • presentation (~ 20 mins)
  • split off in to groups (~ 20 mins)
  • back together for discussion (~ 20 mins)
  • socialise

What do we mean by testing?

  • Generally we mean using code to verify that other code is working as expected.
  • Unit testing - do your functions and methods behave correctly?
  • Integration testing - do your units integrate together correctly?
  • End to end testing - does your final analytical pipeline work as expected?

Note:

  • Tests are nothing more than a comparison between an expectation you have about your code and the actual result you obtain. If the two match up, your test passes, if not, your test fails.
  • Some languages have testing functionality built in to them (e.g. Rust) others rely on external frameworks (e.g. R).
  • No need to use a testing framework for this but they can make your life easier.

Our own analysis

  • If you have trust in your dependencies (why use them if not) then there is no need to test functions you use from those packages.
  • Complexity of your functions can be a good gauge of where to test. However, even with “simple” functions, you can easily make mistakes.
  • When you think your workflow is working as desired, snapshot the end result to ensure future revisions to not alter this output.

Code coverage

My thoughts

  • You are likely already testing your code but in a less structured way.
  • Be proportional based on the project requirements.
  • Testing has saved me so much time and caught many, many errors I've made.
  • Hugely beneficial for my own packages and when contributing to others.
  • Not a panacea.